Fluid Framework

Architecture

マージ処理のロジックを極力クライアントに持たせることで、サーバー側の負荷を減らし、短い遅延でマージ処理ができるらしい

Fluid containerがクライアントのロジックを担う

Fluid service

クライアントから修正(ops)を受け付けて、他のクライアントにbroadcast

AzureでFluid serviceがmanaged serviceとして提供されているらしい（まだprivate preview）

Total order broadcast & eventual consistency

Operational transformation（っぽいこと）をしているらしい

In Fluid, when data is changed, the change is modeled as an operation (often shortened to op) on the existing data (if you’ve used Operational Transform, this concept may sound familiar).

各クライアントからのopsにFluid serviceが単調増加する番号を振って、各クライアントにbroadcast

保存するのはあくまでもopsだけ

送られたopsが増えてきたら時々summarize

Types of distributed data structures

SharedMap

単純なkvs。last-writer-wins merge policy。

変更の単位をkey単位でしか管理できない（valueに複雑な値を入れて、複雑な値の一部だけを変更してもすべてが変更したと見なされる）

SharedNumberSequence・SharedObjectSequence

immutableな値の配列。安全に指定した箇所の値を挿入・削除できる

SharedString

安全な文字列の編集。プレーンテキスト専用？

SharedCounter

安全なカウンター

TaskManager

ここまでに挙げたものと異なり、楽観的でない

変更を加える際に、クライアント間での合意が必要

FAQ

OTもCRDTも使っていないらしい！（両方から強い影響は受けているとのことだが）